衡量最小可行化产品
真正的分析工作始于你开发、上线最小可行化产品的那一刻,这是因为客户与最小可行化产品的每一次交互均会生成可供分析的数据。
初学者需选择自己的第一关键指标。如果不明确指标内容,也还未定义“成功”的样子,就不应着手开发产品。初期最小可行化产品中的每个元素,都应与第一关键指标有关并对其产生影响。立场必须要明确。
本阶段,任何用户获取方面的数据指标都是没有意义的。要想证明产品是否有效,根本用不到数以十万计的用户,甚至连几千用户都用不到。即便是最为复杂的生意行为,依然可以在很大程度上缩小测试用户的范围。
如果你开发的是一个二手交易市场,则可能需要重点关注小型地理区域,如迈阿密地区的二手房买卖。
这种情况同样适用于基于位置的应用。对于这些应用而言,密度远比面积更为重要。例如,现场旧货出售服务仅限于一两个小区以内。
你可以选择一种产品类型作为双边市场的测试对象,例如用20世纪80年代的X战警漫画来验证市场能否正常运转,然后再扩展到其他门类。
也许你还想测试游戏的核心机制。首先发布一款小游戏作为单独的应用程序,然后看看用户的参与度如何。
你或许正在开发一款供家长互相联系的应用。先在一所学校里测试下效果。
关键在于找出创业中风险最大的部分,然后通过反复的测试与学习化解风险。数据指标是你衡量和了解风险是否得以化解的工具。
企业家、作家兼投资人蒂姆·费里斯在一次访谈中曾对凯文·罗斯提到,如果你专注于服务好10 000个人,力图使他们开心快乐,总有一天你可以让数百万人开心。13 首次发布最小可行化产品时,你可以适当缩小目标群体的数量。但费里斯的观点完全正确,即要想获得实质性的进展,全身心的关注与投入十分必要。
13 http://youtu.be/ccFYnEGWoOc
最重要的数据指标与用户参与度有关。人们真的在使用这款产品吗?他们是如何使用产品的?他们使用了产品的全部功能还是部分功能?产品的使用情况和用户行为是否符合我们的预期?
在找到有关使用情况和用户参与度的对应指标以前,不要开发任何功能。子指标最后会汇聚为第一关键指标,这些数据片段汇集在一起后会全面地反映问题。如果你尚不能实现某个功能或产品模块,则需慎重对待功能或模块的添加问题,因为这会带来越来越难控制的变数。
即便你已在关注某一指标,也要确定这么做是否能带来价值。比方说,你发布了一款新的SaaS产品,并假设如果用户在30天内没有使用过该产品的话,即可认定用户的流失。也就是说,你要等30天才能得知流失率是多少。耗时实在是太久了。客户流失时有发生,但如不及时去除流失客户,则可能会导致用户参与度被高估。即便产品的初期参与度很好,也仍需查看自己是否真的传递了价值。例如,你可以查看用户两次访问的时间间隔。时间间隔是一样的,还是在逐渐拉长?在这一过程中,你可能会发现有用的先行指标。
不要忽视定性分析
你应该在整个最小可行化产品的迭代过程中与用户和客户保持不间断的交流。他们获得了你的产品,你也可以从他们身上学到很多。此时此刻,他们不太可能对你说谎或阿谀奉承,毕竟你已对他们有所承诺,他们现在对你的产品有着很高的期待。早期试用者十分宽容,他们可以忍受(事实上很希望看到)粗糙的半成品,但与此同时,随着最小可行化产品使用时间的增长,他们给出的反馈也越来越诚实与透明。
为删除功能做准备
这是一个非常艰难的选择,却可以带来巨大的变化。如果一项功能无人问津,或是不具备使用价值,则应删除该功能,然后看看会发生什么。成功删除某项功能后,继续观察现有用户的参与度和使用情况。这一切和之前有区别吗?
如果根本没人在乎功能的有无,那么你至少把产品清理干净了。如果现有用户对此表示反对,你可能就需要重新审视自己的决定了。如果出现了一群对该功能存在需求的用户,但他们在功能删除前却从未见过这项功能,则这些人可能代表着一种新的群体,其需求与现有用户基础有所不同。
删除功能后你的关注点和价值定位的范围均缩小了,而这应对用户的回馈产生影响。